Method and system for requesting and granting PoC user media transmission right

ABSTRACT

Provided is a method and system for requesting and granting a media transmission right of a PoC user. The method includes a PoC client transmitting an MBCP Request message to a PoC server, the PoC server receiving the MBCP Request message, determining whether a current state corresponds to a media transmission denial condition, and if it is determined that the current state corresponds to a media transmission denial condition, transmitting an MBCP Deny message containing at least one of time information of a media transmission timer and time information of a retry-after timer to the PoC client, and the PoC client receiving the MBCP Deny message, activating the media transmission timer and the retry-after timer using the respective time information, and re-transmitting the MBCP Request message to the PoC server if one of the media transmission timer and the retry-after timer, the retry-after timer having a longer time value, expires.

PRIORITY

This application claims priority under 35 U.S.C. §119(a) to a PatentApplication filed in the Korean Intellectual Property Office on Sep. 27,2006 and assigned Serial No. 2006-94204, the contents of which areincorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a method and system forrequesting and granting Push-To-Talk (PTT) over Cellular (PoC) usermedia transmission right. In particular, the present invention relatesto a method and system optimized for a PoC user to request and receivemedia transmission right in a PoC network in which queuing is notsupported.

2. Description of the Related Art

The significant development of mobile communication and the spread ofcommunication networks have contributed to various extra services andapplications using a cellular phone. At the same time, demand amongcellular phone users for various extra services, such as a positioningservice, a multimedia service, and a Push-To-Talk (PTT) service, isincreasing. Among these extra services, the PTT service supports varioussupplementary functions such as an instant messenger function and astatus display function, as well as supporting a group call and a voicecall, which are also provided by an existing radio or a Trunked RadioSystem (TRS).

Currently, standardization of a PTT-over-Cellular (PoC) service, whichemploys the PTT function in a mobile communication network, is activelybeing developed. One unique feature of the PoC service, which isdistinguished from existing mobile communication services, is that auser can participate in a plurality of PoC sessions and can move amongthe PoC sessions to use a call service. A requirement that the user canmove among the plurality of PoC sessions to use the call service isspecified in the Open Mobile Alliance (OMA), which is a forum forspecifying mobile communications services.

FIG. 1 is a schematic diagram of a conventional PoC service system.Referring to FIG. 1, a PoC client 102, which is a service requesterinstalled in a PoC user terminal 100, is connected to a SessionInitiation Protocol/Internet Protocol (SIP/IP) core network 120, whichsupports SIP and IP multimedia functions, via an access network 110.

The PoC client 102 resides in the PoC user terminal 100 to provideaccess to the PoC service. The PoC client 102 mainly serves a PoC userto initiate a PoC session, participates in a PoC session that iscurrently proceeding, and terminates a PoC session. In addition, the PoCclient 102 acts to make and transfer a talk burst, support an instantpersonal alert, and perform authentication when accessing the PoCservice. Hereinafter, unless otherwise stated, the PoC client 102 isassumed to be the same as a PTT service subscriber.

The SIP/IP core network 120 is connected to a PoC server 150, a PoCExtensible Markup Language Document Management Server (XDMS) 140, and aPoC box 180 in order to support the PoC service.

The PoC server 150 has a controlling PoC function for maintaining andmanaging a PoC session, or a participating PoC function forparticipating in a PoC session established for a one-to-one PoC call ora one-to-many PoC call.

A function of the PoC server 150 is classified into a Controlling PoCFunction (CF) for generally maintaining and managing a PoC session and aParticipating PoC Function (PF) for maintaining and managing each PoCsession, which will be described in more detail with reference to Tables1 and 2.

TABLE 1 Controlling PoC Function (CF) provides centralized PoC sessionhandling Provides the centralized Media distribution Provides thecentralized Talk Burst Arbitration functionality including talkeridentification Provides SIP session handling, such as SIP sessionorigination, termination, etc. Provides policy enforcement forparticipation in group sessions Provides the participants informationCollects and provides centralized media quality information Providescentralized changing report May provide transcoding between differentcodecs Supports Talk Burst Control Protocol Negotiation

As shown in Table 1, the CF serves to generally manage a PoC sessionamong functions of the PoC server 150. The PoC server 150 receivesrequests for a floor (right to talk) from PoC clients, arranges an orderin which to give the clients the floor, and gives the clients the floorin that order. The PoC server 150 also distributes a talk burst from aspecific PoC client to all PoC clients participating in a group PoCcall, and provides information of the PoC clients participating in thegroup PoC call.

As shown in Table 2 below, the PF manages a PoC session between the CFand each PoC client. In particular, the PF acts to relay the floorbetween the PoC client and the CF when the PoC client requests the flooror when the CF gives the floor to the PoC client. In addition, the PFserves to relay media between the CF and the PoC client, providetranscoding between different codecs, and provide a filtering functionfor filtering one of two PoC sessions chosen by a user when there issimultaneous talking in two simultaneous PoC sessions.

TABLE 2 Participating PoC Function (PF) provides PoC session handlingMay provide the Media relay function between PoC Client and ControllingPoC server May provide user media adaptation procedures May provide theTalk Burst control message relay function between PoC Client andControlling PoC server Provides SIP session handling, such as SIPsession origination, termination, etc., on behalf of the represented PoCClient Provides policy enforcement for incoming PoC session (e.g. accesscontrol, incoming PoC session barring, availability status, etc.) Maycollect and provide media quality information Provides the participantcharging reports May provide filtering of the media streams in the caseof simultaneous sessions May provide transcoding between differentcodecs May support Talk Burst Control Protocol Negotiation Stores thecurrent Answer Mode and Incoming PoC Session Barring preferences of thePoC Client

An aggregation proxy server 160 acts to collect requests of all entitiesusing an XML Configuration Access Protocol (XCAP) in the PoC servicesystem and transfer the requests to corresponding entities.

In order to use a PoC call service, the PoC user registers his/her PoCaddress in the SIP/IP core network 120. The SIP/IP core network 120stores information regarding the PoC user at the request of the PoCuser. Thus, when another PoC user tries to request a group PoC call, thePoC user registers his/her information in the SIP/IP core network 120 inadvance as described above, and requests the group PoC call to his/herSIP/IP core network 120 by using group identification informationtransmitted from the PoC XDMS 140. The SIP/IP core network 120 performsaddress determination and domain location determination usinginformation on the call requesting PoC user, and then transfers a PoCcall request to a home PoC server with which the call requesting PoCuser is registered. In regard to the PoC call request, the PoC server150 prepares for establishment of a PoC session, obtains each user'sinformation from the PoC XDMS 140, and then transfers a PoC call requestsignal to a corresponding SIP/IP core network 120. Here, in the case ofa PoC call request to users within an Intradomain, the PoC server 150performs both the CF and PF. The PoC server 150, which manages acall-requested PoC user, requests a PoC call to the PoC user after theSIP/IP core network 120 performs the location determination procedure,by using information on the PoC user that is transmitted to the PoCserver 150. If the call-requested PoC user transmits an OK response tothe call requesting PoC user, a PoC call is connected. When a PoC callis not connected due to a state of another PoC user regardless of a PoCcall request of a PoC user, the PoC user can store his or her voice ormedia desired to transmit, using the PoC box 180.

FIG. 2 is a signaling diagram of a process of requesting and granting amedia transmission right between a PoC client and a PoC server (CF) in aPoC network in which queuing is not supported.

Referring to FIG. 2, if the PoC client transmits a media transmissionright request (Media Burst Control Protocol (MBCP) Request) message forrequesting the media transmission right to the PoC server (CF) in step200, the PoC server (CF) determines in step 202 whether a current statecorresponds to a media transmission denial condition. The mediatransmission denial condition is any of five state conditions of thedenial reasons described below. It is assumed that the current statedoes not correspond to a condition for granting the media transmissionright to the PoC client.

If it is determined in step 202 that the current state corresponds to amedia transmission denial condition, in step 204, the PoC servertransmits a media transmission right request denial (MBCP Deny) messageto the PoC client that has requested the media transmission right.

The PoC client, which has received the MBCP Deny message, informs a PoCuser of a reason for denial contained in the MBCP Deny message.

The five reasons for denial defined in an OMA PoC specification aredescribed below:

1. When another PoC user is transmitting media;

2. An internal error of a PoC server acting as a controlling PoCfunction;

3. When only a PoC client, which has requested a floor, in a relevantsession;

4. When a penalty time (a retry after timer operation) is applied sincethe maximum media transmission time was not observed in previous mediatransmission; and

5. When a subscribing state of a PoC user is a listen only state.

That is, if the current state corresponds to one of the five denialreasons, the PoC server, which has received the MBCP Request message,transmits the MBCP Deny message to the PoC client without granting themedia transmission right. The PoC server determines in step 206 whetherthe current state is free from the media transmission denial condition.

Thereafter, in order for the PoC client to obtain the media transmissionright again, if a media transmission idle (MBCP Idle) message, which isa message having information that no PoC user exists in a PoC session,is received in step 208, the PoC client informs the PoC user of thisstate. If a request for the media transmission right is input by the PoCuser, the PoC client can request a floor again by transmitting the MBCPRequest message to the PoC server in step 210.

FIG. 3 is a message format of the MBCP Deny message transmitted from thePoC server.

Referring to FIG. 3, the first 2-bit field (300) is for a Real-timeTransport Protocol (RTP) Version V. In the case of the presentinvention, the RTP version is 2. The second 1-bit field (301) is for aPadding bit P. It can be seen that if the padding bit P is given, one ortwo padding octets that are not contained in a payload, are added. Thethird 5-bit field (302) indicates a subtype. It can be seen by referringto an OMA PoC User Plane specification which function of a Time BurstControl Protocol (TBCP) a Real-time Transport Control ProtocolApplication (RTCP APP) packet performs using the subtype. For example,in the case of the MBCP Deny message, the subtype has a value defined as00011.

The fourth 1-byte field (303) is for a Packet Type (PT), and is shown asPT=204, which indicates that this message is an RTCP APP packet. Thefifth 2-byte field (304) is for a length field. If a value of 2 is usedin the length field, this indicates that the message has two 4-byteoctets. If the value is followed by a payload, this indicates a lengthof the payload, i.e. how many 4-byte octets exist in the payload. In thecase of the MBCP Deny message, a total size of the MBCP Deny message isdetermined according to a reason phrase.

The sixth 4-byte field (305) is for a Synchronization SouRCe (SSRC)field. This field contains a synchronization source to discriminatesenders of the RTCP APP message. The seventh 4-byte field (306) isexpressed by an American Standard Code for Information Interchange(ASCII), which has a function of discriminating a PoC version accordingto the OMA PoC specification.

Reason code (307) related fields have a value indicating a denialreason. Four denial reasons defined in the OMA PoC specification aredescribed below:

1. If the code value is 1, another PoC user has permission.

2. If the code value is 2, the media transmission right cannot beacquired due to an internal error of a PoC server.

3. If the code value is 3, a retry-after value has not been terminatedyet. The retry-after value is a value of a timer activated by the PoCserver when a PoC user transmitted media by spending his/her entireallowed time. That is, the timer is a penalty timer. Thus, the PoC usercannot acquire the media transmission right regardless of a mediatransmission right request while the timer is operating.

4. If the code value is 4, since the priority of the PoC user who hasrequested the media transmission right is set to ‘Listen only’, the PoCuser cannot transmit but can receive media in a PoC session.

As described above, if a PoC user requests a media transmission rightfrom a PoC server by means of a PoC client, and if the PoC user receivesthe MBCP Deny message in response, the PoC user can request the mediatransmission right again only after receiving an MBCP Idle message fromthe PoC server. That is, the PoC user must wait to receive the MBCP Idlemessage if the PoC user has received the MBCP Deny message.

SUMMARY OF THE INVENTION

An aspect of the present invention is to substantially solve at leastthe above problems and/or disadvantages and to provide at least theadvantages below. Accordingly, an aspect of the present invention is toprovide a media method and system for automatically requesting a mediatransmission right from a PTT over Cellular (PoC) server when the PoCserver can grant the media transmission right to a PoC client regardlessof the fact that the PoC client requested the media transmission rightfrom the PoC server once and received a media transmission right requestdenial (Media Burst Control Protocol (MBCP) Deny) message.

According to one aspect of the present invention, there is provided amethod of requesting and granting a media transmission right of a PoCuser in a PoC system including a PoC client and a PoC server, the methodincluding the PoC client transmitting a media transmission right request(MBCP Request) message to the PoC server according to a request of thePoC user; the PoC server receiving the MBCP Request message, determiningwhether a current state corresponds to a media transmission denialcondition, and if it is determined that the current state corresponds toa media transmission denial condition, transmitting a media transmissionright request denial (MBCP Deny) message containing at least one of timeinformation of a media transmission timer and time information of aretry-after timer to the PoC client; and the PoC client receiving theMBCP Deny message, activating the media transmission timer and theretry-after timer using the respective time information if the timeinformation of the media transmission timer and the time information ofthe retry-after timer are contained in the MBCP Deny message, andre-transmitting the MBCP Request message to the PoC server if one of themedia transmission timer and the retry-after timer, which has a longertime value, expires.

According to another aspect of the present invention, there is provideda system for requesting and granting a media transmission right of a PoCuser, the system including a PoC client for transmitting a mediatransmission right request (MBCP Request) message according to a requestof the PoC user, and if a media transmission right request denial (MBCPDeny) message is received, determining whether time information of amedia transmission timer and time information of a retry-after timer arecontained in the MBCP Deny message, and if the time information of themedia transmission timer and the time information of the retry-aftertimer are contained in the MBCP Deny message, activating the mediatransmission timer and the retry-after timer using the respective timeinformation, and if one of the media transmission timer and theretry-after timer, which has a longer time value, expires,re-transmitting the MBCP Request message; and a PoC server for, if theMBCP Request message is received, determining whether a current statecorresponds to a media transmission denial condition, and if it isdetermined that the current state corresponds to a media transmissiondenial condition, transmitting the MBCP Deny message containing at leastone of the media transmission timer time information and the retry-aftertimer time information to the PoC client.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the presentinvention will become more apparent from the following detaileddescription when taken in conjunction with the accompanying drawing inwhich:

FIG. 1 is a schematic diagram of a conventional PoC system;

FIG. 2 is a signaling diagram of a conventional process of requestingand granting a media transmission right of a PoC user;

FIG. 3 is a message format of a conventional media transmission rightrequest denial (MBCP Deny) message;

FIG. 4 is a signaling diagram of a process of requesting and granting amedia transmission right of a PoC user according to an exemplaryembodiment of the present invention;

FIG. 5 is a signaling diagram of a process of requesting and granting amedia transmission right of a PoC user according to another exemplaryembodiment of the present invention;

FIG. 6 is a signaling diagram of a process of requesting and granting amedia transmission right of a PoC user according to another exemplaryembodiment of the present invention;

FIG. 7 is a flowchart of a process performed by a PoC client tore-transmit a media transmission right request (MBCP Request) messageafter receiving an MBCP Deny message according to an exemplaryembodiment of the present invention; and

FIG. 8 is a message format of an MBCP Deny message according to anexemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Preferred embodiments of the present invention will be described hereinbelow with reference to the accompanying drawings. Hereinafter, there isdescribed a case of applying the present invention to a Push To Talk(PTT) system, in particular, a PTT over Cellular (PoC) system providinga PTT service using a cellular mobile communication network. In general,the PoC system uses a Session Initiation Protocol (SIP) and a SIPextension protocol in order to transfer session participationinformation of a group PoC call, and an extensible markup languageConfiguration Access Protocol (XCAP) in order to obtain groupinformation. The functionality of the present invention described belowcan be implemented using the above-described protocols, and the basicconstruction of the present invention can be based on a PoC Rel.lsystem.

An optimized method used by a PoC user to request a media transmissionright from a PoC server and acquiring the media transmission right fromthe PoC server in a PoC network in which queuing is not supported willnow be described with reference to FIGS. 4 through 6. FIG. 4 is asignaling diagram of a process of transmitting a media transmissionright request denial (MBCP Deny) message containing a stop talking (T2)timer value and a retry-after timer value according to an exemplaryembodiment of the present invention, FIG. 5 is a signaling diagram of aprocess of transmitting an MBCP Deny message containing a T2 timer valueaccording to another exemplary embodiment of the present invention, andFIG. 6 is a signaling diagram of a process of transmitting an MBCP Denymessage containing a retry-after timer value according to anotherexemplary embodiment of the present invention.

Referring to FIG. 4, if a PoC client transmits a media transmissionright request (MBCP Request) message to a PoC server which does notsupport queuing in step 400 in order to request a media transmissionright, the PoC server determines in step 402 whether a current statecorresponds to one of the media transmission denial conditions describedabove when the MBCP Request message is received.

In the current embodiment, the PoC server determines whether a currentstate corresponds to one of the media transmission denial conditions bydetermining whether media of another PoC user is being transmitted orwhether a retry-after timer is activated. If the current statecorresponds to one of the two determined conditions, the PoC servertransmits an MBCP Deny message to the PoC client. According to thepresent invention, a stop talking (T2) timer value according to whethermedia of another PoC user is being transmitted and/or a retry-aftertimer value according to whether the retry-after timer is activated arecontained in the MBCP Deny message and transmitted. As a result of thedetermination of whether the current state corresponds to one of themedia transmission denial conditions, the T2 timer value is contained inthe MBCP Deny message if a T2 timer is activated since media of anotherPoC user is being transmitted, the retry-after timer value is containedin the MBCP Deny message if media of another PoC user is not beingtransmitted but the retry-after timer is activated for the PoC client,or the T2 timer value and the retry-after timer value are contained inthe MBCP Deny message if the current state corresponds to both the twodetermination conditions, i.e. if media of another PoC user is beingtransmitted and the retry-after timer is activated for the PoC client.

The T2 timer is a media transmission time timer, and the retry-aftertimer is a penalty timer for the PoC client. In more detail, the T2timer value is an initial value when the PoC server begins to transmitmedia transmitted by the PoC client to a target PoC client or group, anddecreases on a second basis while the media is being transmitted. Forexample, if the initial value of the T2 timer is 30 and 14 seconds haselapsed, the T2 timer value is 16. The T2 timer value of 16 means thatthe PoC server is going to transmit media of a relevant PoC user for 16seconds more. The retry-after timer value decreases on asecond-by-second basis from an initial value to 0. The retry-after timeris used to deny a media transmission right regardless of a request forthe media transmission right of the PoC user until the retry-after timervalue becomes 0. For example, if the retry-after timer value is 20, thePoC user cannot acquire the media transmission right for 20 seconds,regardless of a request for the media transmission right.

Since the MBCP Deny message in the exemplary embodiment of FIG. 4contains both a T2 timer value and a retry-after timer value, the PoCserver transmits the MBCP Deny message containing MBCP Request messageacceptable time information to the PoC client in step 404. The MBCPRequest message acceptable time information indicates the T2 timer valueand the retry-after timer value, which are media transmission timeinformation. In the exemplary embodiment of FIG. 4, the MBCP Denymessage containing the two pieces of time information is transmitted.After transmitting the MBCP Deny message, the PoC server determines instep 406 whether the current state is free from the media transmissiondenial condition. That is, it is determined whether a media transmissionrelease (MBCP Release) message is received from another PoC clientmessage or whether the T2 timer or the retry-after timer expires. If anyone is satisfied, the PoC server transmits a media transmission idle(MBCP Idle) message to the PoC client in step 408.

The PoC client, which has received the MBCP Deny message in step 404,activates the T2 timer with the T2 timer value and simultaneouslyactivates the retry-after timer with the retry-after timer value in step410. That is, if the PoC server transmits the MBCP Deny messagecontaining time information of the T2 timer and time information of theretry-after timer, the PoC client informs the PoC user what is a currentdenial reason and that the media transmission right is going to berequested after the T2 timer value or the retry-after timer value. Whenthe two pieces of time information are simultaneously received, the twopieces of time information are compared to each other, and the mediatransmission right is requested after one of the T2 timer and theretry-after timer, which has a longer time value, expires.

The PoC client determines in step 412 whether the MBCP Idle message hasbeen received. If it is determined in step 412 that the MBCP Idlemessage has been received, the PoC client determines in step 418 whetherthe retry-after timer has expired. If it is determined in step 418 thatthe retry-after timer has expired, the PoC client automaticallytransmits the MBCP Request message to the PoC server in step 420.

In this case, the PoC client may automatically transmit the MBCP Requestmessage when a retry condition is satisfied, i.e. when the retry-aftertimer expires, as described above, or may inform the PoC user that theMBCP Request message can be transmitted, and transmit the MBCP Requestmessage to the PoC server according to the PoC user's selection. Inaddition, when the MBCP Request message is automatically transmitted, amessage for informing the PoC user that the MBCP Request message hasbeen automatically transmitted may be displayed on a screen.

If it is determined in step 412 that the MBCP Idle message has not beenreceived, the PoC client determines in step 414 whether one of the T2timer and the retry-after timer, the retry-after timer having a longertime value, has expired. If it is determined in step 414 that the timerhaving a longer time value has expired, the PoC client transmits theMBCP Request message to the PoC server in step 416. Otherwise, theprocess continues to step 412. That is, the PoC client activates theretry-after timer based on the time information contained in the MBCPDeny message, calculates the time a media transmission time ends, andrequests the media transmission right without a request of the PoC userat the calculated time. For example, when the MBCP Deny messagecontaining the two pieces of time information is received, a timer isactivated based on time information having a longer time value among thetwo pieces of time information as described above, and when the timerexpires, the media transmission right is requested.

FIG. 8 is a message format of an MBCP Deny message containing T2 timertime information and retry-after time information, which is transmittedfrom a PoC server to a PoC client according to an exemplary embodimentof the present invention.

Referring to FIG. 8, the first 2-bit field is for a Real-time TransportProtocol (RTP) version. In the case of the present invention, the RTPversion is 2. The second 1-bit field (801) is for a padding bit P. Itcan be seen that if the padding bit P is given, one or two paddingoctets that are not contained in a payload, are added. The third 5-bitfield (802) indicates a subtype. It can be seen by referring to the OMAPoC User Plane specification which function of a Time Burst ControlProtocol (TBCP) a Real-time Transport Control Protocol Application (RTCPAPP) packet performs using the subtype. For example, in thespecification that is currently drafted in the OMA, the subtype has avalue defined as 00011 for an MBCP Deny message. The fourth 1-byte field(803) is for a Packet Type (PT), and is shown as PT=204, which indicatesthat this message is an RTCP APP packet. The fifth 2-byte field (804) isfor a length field. If a value of 2 is used in the length field, thisindicates that the message has two 4-byte octets. If the value isfollowed by a payload, this indicates a length of the payload, i.e. howmany 4-byte octets exist in the payload. In the case of the MBCP Denymessage, a total length of the MBCP Deny message is determined accordingto a reason phrase. The sixth 4-byte field (805) is for aSynchronization SouRCe (SSRC) field. This field contains asynchronization source to discriminate who sent the RTCP APP message.The seventh 4-byte field (806) is expressed by American Standard Codefor Information Interchange (ASCII), which has the function ofdiscriminating a PoC version according to the OMA PoC specification.Reason code (807) related fields have a value indicating a denialreason.

That is, the fields before a T2 timer information ID field (808) are thesame as those of the conventional MBCP Deny message illustrated in FIG.3. That is, the MBCP Deny message according to an exemplary embodimentof the present invention further includes the T2 timer information IDfield (808), a length field (809), a currently activated T2 timer timeinformation value field (810), a retry-after timer information ID field(811), a length field (812), and a retry-after timer time informationvalue field (813).

The T2 timer information ID field and the retry-after timer informationID field are used to identify that the MBCP Deny message contains T2timer information or retry-after timer time information. Each lengthfield indicates the length of the T2 timer or retry-after timer value,which follows the length field. The T2 timer time information valuefield and the retry-after timer time information value fieldrespectively have a value of the T2 timer activated by the PoC server,which is a media transmission time value of another PoC user, and avalue of the retry-after timer currently activated by the PoC server forthe PoC client.

A process of transmitting an MBCP Deny message containing a T2 timervalue in a PoC server according to another exemplary embodiment of thepresent invention will now be described with reference to FIG. 5.

Steps 500, 502, 506, and 508 of FIG. 5 are respectively to the same assteps 400, 402, 406, and 408 of FIG. 4.

Referring to FIG. 5, the PoC server determines in step 502 whether acurrent state corresponds to one of the media transmission denialconditions described above when an MBCP Request message is received. Ifit is determined in step 502 that the T2 timer is activated since mediaof another PoC user is being transmitted, the PoC server transmits anMBCP Deny message containing a T2 timer value to a PoC client in step504.

The PoC client, which has received the MBCP Deny message, activates a T2timer using the T2 timer value contained in the MBCP Deny message instep 510. The PoC client determines in step 512 whether an MBCP Idlemessage has been received. If it is determined in step 512 that the MBCPIdle message has been received, the PoC client transmits the MBCPRequest message to the PoC server in step 514.

If it is determined in step 512 that the MBCP Idle message has not beenreceived, the PoC client determines in step 516 whether the T2 timer hasexpired. If it is determined in step 516 that the T2 timer has expired,the PoC client transmits the MBCP Request message to the PoC server instep 518. Otherwise, the process continues to step 512. For example, itis assumed that a specific PoC client has transmitted an MBCP Requestmessage to the PoC server and received an MBCP Deny message containing aT2 timer value of 20. That is, this means that another PoC client isbeing transmitted media and that the remaining transmission time is 20seconds. Thus, the specific PoC client activates a T2 timer having aninitial value of 20 and re-transmits the MBCP Request message to the PoCserver without a re-request of a PoC user when the T2 timer expires. Ifan MBCP Idle message is received from the PoC server before the T2 timerexpires, since this means that no PoC client transmits media, thespecific PoC client immediately transmits the MBCP Request message tothe PoC server even before the 20 seconds elapse.

In steps 514 and 518, when the PoC client transmits the MBCP Requestmessage to the PoC server, a message for informing the PoC user that theMBCP Request message has been automatically transmitted may be displayedon a screen. In addition, the PoC client may not automatically transmitthe MBCP Request message, but may inform the PoC user that the MBCPRequest message can be transmitted and transmit the MBCP Request messageto the PoC server according to the PoC user's selection.

A process of transmitting an MBCP Deny message containing a retry-aftertimer value in a PoC server according to another exemplary embodiment ofthe present invention will now be described with reference to FIG. 6.

Steps 600, 602, 606, and 608 of FIG. 6 are respectively the same asequal to steps 400,402, 406, and 408 of FIG. 4.

Referring to FIG. 6, the PoC server determines in step 602 whether acurrent state corresponds to one of the media transmission denialconditions described above when an MBCP Request message is received. Ifit is determined in step 602 that media of another PoC user is not beingtransmitted but a retry-after timer is activated for a PoC client, thePoC server transmits an MBCP Deny message containing a retry-after timervalue to the PoC client in step 604.

The PoC client, which has received the MBCP Deny message activates aretry-after timer using the retry-after timer value contained in theMBCP Deny message in step 610. The PoC client determines in step 612whether the retry-after timer has expired. If it is determined in step612 that the retry-after timer has expired, the PoC client transmits theMBCP Request message to the PoC server in step 614. Unlike theembodiment of FIG. 5, in FIG. 6, whether an MBCP Idle message isreceived is not determined because even if the PoC client has receivedthe MBCP Idle message, if a retry-after timer for the PoC client isactivated in the PoC server, the PoC server does not grant the mediatransmission right to the PoC client regardless of a request for themedia transmission right of the PoC client until the retry-after timerfor the PoC client expires.

FIG. 7 is a flowchart of a process performed by a PoC client tore-transmit a media transmission right request (MBCP Request) messageafter receiving an MBCP Deny message according to an exemplaryembodiment of the present invention.

In an idle state of step 700, if a media transmission request is inputby a PoC user, the PoC client transmits an MBCP Request message to a PoCserver in step 702. If an MBCP Deny message is received from a PoCserver in step 704, the PoC client determines in step 706 whether theMBCP Deny message contains a T2 timer value or a retry-after timervalue. If it is determined in step 706 that the MBCP Deny messagecontains neither the T2 timer value nor the retry-after timer value,according to a conventional media retransmission request method, the PoCuser directly controls the PoC client to re-transmit the MBCP Requestmessage to the PoC server after an MBCP Idle message is received. Theconventional media retransmission request method is omitted in FIG. 7.

If it is determined in step 706 that the MBCP Deny message contains boththe T2 timer value and the retry-after timer value, i.e. two timervalues, the process continues to step 712. If it is determined in step706 that the MBCP Deny message contains the T2 timer value, the processcontinues to step 720. If it is determined in step 706 that the MBCPDeny message contains the retry-after timer value, the process continuesto step 708.

If it is determined in step 706 that the MBCP Deny message contains boththe T2 timer value and the retry-after timer value, i.e. the two timervalues, the PoC client activates a T2 timer and a retry-after timerusing the two timer values in step 712. The PoC client determines instep 714 whether an MBCP Idle message has been received. If it isdetermined in step 714 that the MBCP Idle message has been received, thePoC client determines in step 716 whether the retry-after timer hasexpired. If it is determined in step 716 that the retry-after timer hasexpired, the PoC client transmits the MBCP Request message to the PoCserver in step 726. If it is determined in step 714 that the MBCP Idlemessage has not been received, the PoC client determines in step 718whether one of the T2 timer and the retry-after timer, the retry-aftertimer having a longer time value, has expired. If it is determined instep 718 that the timer having a longer time value has expired, the PoCclient transmits the MBCP Request message to the PoC server in step 726.

If it is determined in step 706 that the MBCP Deny message contains onlythe T2 timer value, the PoC client activates a T2 timer in step 720, anddetermines in step 722 whether an MBCP Idle message has been received.If it is determined in step 722 that the MBCP Idle message has beenreceived, the PoC client transmits the MBCP Request message to the PoCserver in step 726. If it is determined in step 722 that the MBCP Idlemessage has not been received, the PoC client determines in step 724whether the T2 timer has expired. If it is determined in step 724 thatthe T2 timer has expired, the PoC client transmits the MBCP Requestmessage to the PoC server in step 726.

If it is determined in step 706 that the MBCP Deny message contains onlythe retry-after timer value, the PoC client activates a retry-aftertimer using the retry-after timer value in step 708. The PoC clientdetermines in step 710 whether the retry-after timer has expired. If itis determined in step 710 that the retry-after timer has expired, thePoC client transmits the MBCP Request message to the PoC server in step726.

The MBCP Request message of step 726 may be re-transmitted by storingthe MBCP Request message of step 702 in a memory of the PoC client andreading the stored MBCP Request message. In addition, when the PoCclient re-transmits the MBCP Request message to the PoC server in step726, a message for informing the PoC user that the MBCP Request messagehas been automatically retransmitted may be displayed on a screen. Inaddition, the PoC client may not automatically transmit the MBCP Requestmessage, but may inform the PoC user that the MBCP Request message canbe transmitted and transmit the MBCP Request message to the PoC serveraccording to the PoC user's selection.

As described above, according to the present invention, even if arequest for a media transmission right is denied, a PoC client can storean MBCP Request message and transmit the stored MBCP Request messagewithout a PoC user's re-request when a timer expires or when an MBCPIdle message is received, and thus, a media transmission right requesttime can be reduced, and the efficiency of an overall PoC networkoperation can be increased.

While the invention has been shown and described with reference to acertain preferred embodiment thereof, it will be understood by thoseskilled in the art that various changes in form and details may be madetherein without departing from the spirit and scope of the invention asdefined by the appended claims.

What is claimed is:
 1. A method of requesting and granting a mediatransmission right of a PTT over Cellular (PoC) user in a PoC system,which includes a PoC client and a PoC server, the method comprising: thePoC client transmitting a media transmission right request (Media BurstControl Protocol (MBCP) Request) message to the PoC server according toa request of the PoC user; the PoC server receiving the MBCP Requestmessage, determining whether a current state corresponds to a mediatransmission denial condition, and if it is determined that the currentstate corresponds to a media transmission denial condition, transmittinga media transmission right request denial (MBCP Deny) message containingat least one of time information of a media transmission timer and timeinformation of a retry-after timer to the PoC client; and the PoC clientreceiving the MBCP Deny message, if the time information of the mediatransmission timer and the time information of the retry-after timer arecontained in the MBCP Deny message, activating the media transmissiontimer and the retry-after timer using respective time information, andre-transmitting the MBCP Request message to the PoC server if one of themedia transmission timer and the retry-after timer, the retry-aftertimer having a longer time value, expires.
 2. The method of claim 1,further comprising the PoC client storing the MBCP Request message aftertransmitting the MBCP Request message according to the request of thePoC user.
 3. The method of claim 2, further comprising, if a mediatransmission idle (MBCP Idle) message is received while activating themedia transmission timer and the retry-after timer, the PoC clientdetermining whether the retry-after timer has expired, and if it isdetermined that the retry-after timer has expired, re-transmitting theMBCP Request message.
 4. The method of claim 2, further comprising: ifthe time information of the media transmission timer is contained in theMBCP Deny message received by the PoC client, the PoC client activatingthe media transmission timer using the time information of the mediatransmission timer; determining whether an MBCP Idle message is receivedwhile activating the media transmission timer, and if it is determinedthat the MBCP Idle message is received, re-transmitting the MBCP Requestmessage; and if the media transmission timer expires, re-transmittingthe MBCP Request message.
 5. The method of claim 2, further comprising:if the time information of the retry-after timer is contained in theMBCP Deny message received by the PoC client, activating the retry-aftertimer using the time information of the retry-after timer; and if theretry-after timer expires, re-transmitting the MBCP Request message. 6.The method of claim 2, wherein when the PoC client re-transmits the MBCPRequest message, the PoC client re-transmits a stored MBCP Requestmessage.
 7. The method of claim 6, further comprising the PoC clientre-transmitting the MBCP Request message and simultaneously informingthe PoC user that the MBCP Request message is re-transmitted.
 8. Asystem for requesting and granting a media transmission right of a PTTover Cellular (PoC) user, the system comprising: a PoC client fortransmitting a media transmission right request (MBCP Request) messageaccording to a request of the PoC user, and if a media transmissionright request denial (MBCP Deny) message is received, determiningwhether time information of a media transmission timer and timeinformation of a retry-after timer are contained in the MBCP Denymessage, and if the time information of the media transmission timer andthe time information of the retry-after timer are contained in the MBCPDeny message, activating the media transmission timer and theretry-after timer using respective time information, and if one of themedia transmission timer and the retry-after timer, which has a longertime value, expires, re-transmitting the MBCP Request message; and a PoCserver for, if the MBCP Request message is received, determining whethera current state corresponds to a media transmission denial condition,and if it is determined that the current state corresponds to a mediatransmission denial condition, transmitting the MBCP Deny messagecontaining at least one of the media transmission timer time informationand the retry-after timer time information to the PoC client.
 9. Thesystem of claim 8, wherein the PoC client stores the MBCP Requestmessage after transmitting the MBCP Request message according to therequest of the PoC user.
 10. The system of claim 9, wherein if a mediatransmission idle (MBCP Idle) message is received while activating themedia transmission timer and the retry-after timer, the PoC clientdetermines whether the retry-after timer has expired, and if it isdetermined that the retry-after timer has expired, re-transmits the MBCPRequest message.
 11. The system of claim 9, wherein if the timeinformation of the media transmission timer is contained in the MBCPDeny message received by the PoC client, the PoC client activates themedia transmission timer using the time information of the mediatransmission timer, determines whether an MBCP Idle message is receivedwhile activating the media transmission timer, and if it is determinedthat the MBCP Idle message is received, re-transmits the MBCP Requestmessage.
 12. The system of claim 11, wherein if the media transmissiontimer expires, the PoC client re-transmits the MBCP Request message. 13.The system of claim 9, wherein if the time information of theretry-after timer is contained in the MBCP Deny message received by thePoC client, the PoC client activates the retry-after timer using thetime information of the retry-after timer, and if the retry-after timerexpires, re-transmits the MBCP Request message.
 14. The system of claim9, wherein when the PoC client re-transmits the MBCP Request message,the PoC client re-transmits the stored MBCP Request message.
 15. Thesystem of claim 14, wherein the PoC client re-transmits the MBCP Requestmessage and simultaneously informs the PoC user that the MBCP Requestmessage is re-transmitted.
 16. A method of granting a media transmissionright of a user by a server, the method comprising: receiving a mediatransmission right request message from a client; determining whether acurrent state corresponds to a media transmission denial condition; ifit is determined that the current state corresponds to the mediatransmission denial condition, transmitting, to the client, a mediatransmission right request denial message including time information ofa media transmission timer and time information of a retry-after timerfor re-transmitting the media transmission right request message; andreceiving a re-transmission of the media transmission right request fromthe client, when one of the media transmission timer and the retry-aftertimer having a longer duration expires.
 17. The method of claim 16,wherein determining whether the current state corresponds to the mediatransmission denial condition comprises determining whether media ofanother user is being transmitted or whether the retry-after timer isactivated.
 18. The method of claim 16, further comprising: determiningwhether the current state still corresponds to the media transmissiondenial condition, after transmitting the media transmission rightrequest denial message; and transmitting a media transmission idlemessage to the client, when the current state no longer corresponds tothe media transmission denial condition.
 19. A method of requesting amedia transmission right of a user by a client, the method comprising:transmitting a media transmission right request message to a server;receiving a media transmission right request denial message includingtime information of a media transmission timer and time information of aretry-after timer for retransmitting the media transmission rightrequest message; activating the media transmission timer and theretry-after timer; and re-transmitting the media transmission rightrequest to the server, if one of the media transmission timer and theretry-after timer having a longer duration expires.
 20. The method ofclaim 19, further comprising: receiving a media transmission idlemessage from the server when the media transmission timer and theretry-after timer are activated; and re-transmitting the mediatransmission right request message to the server, when the retry-aftertimer expires.
 21. The method of claim 20, further comprising:re-transmitting the media transmission right request message to theserver, if the media transmission timer expires.
 22. The method of claim19, further comprising storing the media transmission right requestmessage.
 23. A server for granting a media transmission right of a user,the server comprising: a hardware processor for receiving a mediatransmission right request message from a client, determining whether acurrent state corresponds to a media transmission denial condition, ifit is determined that the current state corresponds to the mediatransmission denial condition, transmitting, to the client, a mediatransmission right request denial message including time information ofa media transmission timer and time information of a retry-after timerfor re-transmitting of the media transmission right request message, andreceiving a re-transmission of the media transmission right request fromthe client, when one of the media transmission timer and the retry-aftertimer having a longer duration expires.
 24. The server of claim 23,wherein the hardware processor determines whether the current statecorresponds to the media transmission denial condition based on whethermedia of another user is being transmitted or whether the retry-aftertimer is activated.
 25. The server of claim 23, wherein the hardwareprocessor determines whether the current state still corresponds to themedia transmission denial condition, after transmitting the mediatransmission right request denial message, and transmits a mediatransmission idle message to the client, when the current state nolonger corresponds to the media transmission denial condition.
 26. Aterminal for requesting a media transmission right of a user, theterminal comprising: a client for transmitting a media transmissionright request message to a server, receiving a media transmission rightrequest denial message including time information of a mediatransmission timer and time information of a retry-after timer forre-transmitting the media transmission right request message, activatingthe media transmission timer and the retry-after timer, andre-transmitting the media transmission right request to the server, ifone of the media transmission timer and the retry-after timer having alonger duration expires.
 27. The terminal of claim 26, wherein theclient determines if a media transmission idle message is received fromthe server, and re-transmits the media transmission right requestmessage to the server when the retry-after timer expires, if the mediatransmission idle message is received.
 28. The terminal of claim 26,wherein the client determines if a media transmission idle message isreceived from the server, and re-transmits the media transmission rightrequest message to the server, if the media transmission idle message isreceived.
 29. The terminal of claim 26, wherein the client stores themedia transmission right request message.